The invention relates to an information processing system and a method, in particular, but not exclusively, for control of consumer electronics equipment in the home or office environment.
Consider a computing model based on Component Object Model (COM/DCOM) technology of Microsoft. For more information, see, e.g., the Component Object Model Specification version 0.9 of October 1995 as supplied by Microsoft, herein incorporated by reference. COM is object-oriented. An object has properties that represent control functionalities of an associated electronic device as exposed to a software application. A state change of an object as a consequence of an event from outside is passed on to the software application. The application manipulates the objects by changing or setting their properties. When the application modifies a property of an object associated with a certain physical device a command is sent to the associated device.
COM is a generic mechanism allowing applications to communicate in a consistent way and is a framework for developing and supporting program component objects. It provides capabilities similar to those defined in CORBA (Common Object Request Broker Architecture), the framework for the interoperation of distributed objects in a network. OLE (object linking and embedding) provides services for the compound document that users see on their display, COM provides the underlying services of interface negotiation and event services (putting one object into service as the result of an event that has happened to another object). In this implementation clients are modeled as OLE Automation objects (abstract representations) that use properties to expose controls and events to signal state changes. OLE Automation is a COM technology that enables scripting and late binding of clients to servers. OLE Automation provides communication with other programs through calls to features (commands and queries) that the programs have made available for external use. Before using an object, a client application has first to obtain the object""s interface pointer. The interface pointer is obtained through the network""s directory by binding the object""s name or by enumerating devices. Standard COM API""s for moniker binding can be used. References to objects can be obtained by calling GetObject or CoGetObject with a string specifying the desired device""s name or ID. The application can then manipulate the object by setting or retrieving its properties through xe2x80x9cset propertyxe2x80x9d calls to the appropriate properties. When an application sets or modifies a property of an object corresponding with a device the property-setting operation or modification operation is converted into a command that is sent across the network to the relevant device. The objects may differ in implementation, but expose a similar property-based model to client applications running on a controller, e.g., a PC with a Windows-based operating system.
Consider an information processing system comprising such objects (i.e., a collection of software modules, e.g., as introduced above) and client software applications that control the interaction among the objects. For example, the system comprises a home automation sub-system with audio/video equipment for entertainment, a security sub-system and an inhouse-climate control sub-system. These sub-systems and their components are modeled as, e.g., OLE Automation objects that use properties to expose their controls to application clients and events to signal state changes to the application clients. The sub-systems may use different communication protocols for their control signals. Accordingly, since they cannot communicate with each other directly, they communicate at the object-level. A client application could register for notification of changes to the xe2x80x9cstatexe2x80x9d property of a first object representing a first (software) sub-system or first device and respond by setting a specific property of a second object representing a second sub-system or second device. However, the client application would need to be running all the time to provide this interaction. An alternative solution is therefore to specify that, whenever a change occurs to a property of a first object, the property""s new value be propagated as a SetProperty call to a property of a second object. This mechanism is being referred to as a property route. A property route interconnects objects and is registered at the network""s directory as a system-wide OLE Automation object itself. Registering a route creates a link between properties, typically, but not necessarily, between properties of different objects. Whenever a first property changes, the change triggers a call to change a second property via the registered route interconnecting these properties. For more background on a home automation system of the above kind see, for example, Ser. No. 09/146,020 filed Sep. 2, 19998 for Yevgeniy Shteyn for xe2x80x9cLOW DATA-RATE NETWORK REPRESENTED ON HIGH DATA-RATE HAVi-NETWORKxe2x80x9d, herein incorporated by reference.
Now, consider such a system with an object, a property of which is controllable through a state change from each of multiple other objects via property routes. Consider, for example, a lighting system wherein a light is controllable through two switches at two different locations. The two switches are represented by first and second software objects and the light is represented by a third software object. A first client application registers a first property route so that a change of a state of the first switch object propagates to the third light object to cause a corresponding state change of its brightness property. A second application registers a second property route to control the brightness of the light through a state change of the second switch object. Now, when the second switch changes its state to xe2x80x9cONxe2x80x9d, the light""s brightness goes to 100%. The state of the first switch is not updated, unless a third route has been registered for propagating the light""s brightness state to the first switch. However, in many cases such behavior seems counter-intuitive as it requires a conscious effort from the user or application developer to keep the system synchronized. It also requires the system to use complicated logical rules to avoid looping route propagation. The state change of the light propagated to the first object may cause a call from the first switch object to the light object and thus a change in its brightness, etc.
As another example, consider a home entertainment system, wherein a particular functionality (e.g., sound volume) of an apparatus is controllable both through a physical slider at a control panel, and through a remote control device. Assume that the slider and remote control device are represented by first and second software objects and that the controllable functionality of the equipment is represented by a third software object. A first client application registers a first property route so that a change of a state of the slider object propagates to the third object to cause a corresponding state change in the volume property. A second application registers a second property route to control the sound volume through a state change of the object associated with the remote control. In order to keep the first, second and third object synchronized, one could register routes that propagate the state changes of the apparatus to the controls. This, however, renders the control complicated, as in the light case above, and requires checking for endless loops.
The inventor has realized that the user or the application developer has to make an effort in order to keep the behavior of the system""s components synchronized. The inventor has also realized that it further a requires the system to use a complicated logic rule base in order to prevent the system from entering an endless loop.
It is therefore an objective of the invention to provide a system and a method for controlling physical components through their representations as software objects that facilitates the synchronizing and that avoids endless loops.
To this end, the invention provides an information processing system comprising multiple functionalities, e.g., components of physical devices or services to or from such a component or device. Each respective one of these functionalities is represented by a respective software object. Each software object has one or more properties whose state or parameter value can be changed via an appropriate message (call, command, etc.). The system comprises a route manager through which a two-way property route is invoked. Executing the route enables keeping respective states of the respective properties that are linked through this route consistent with each other. To achieve this the route is executed to change a state of a specific one of the properties upon a change of state of another one of the properties if the change of state of the other property was caused by an effect other than the route itself.
The invention is based on the insight that the conditional execution as specified by the invention is a simple and effective way to avoid endless loops and uncontrolled propagation of state changes through the
The invention also relates to a method of enabling controlling an information processing system. The system has first and second functionalities that are represented by first and second software objects, respectively. The first and second properties have first and second settable properties, respectively. The method comprises enabling invoking a property route between the first and second properties for enabling keeping states of the properties consistent with each other; enabling executing the route to change the state of the first property upon a change of the state of the second property if the change of the state of the second property was caused by an effect other than the route itself; and enabling executing the route to change the state of the second property upon a change of the state of the first property if the change of the state of the first property was caused by an effect other than the route itself.
The expressions xe2x80x9cenabling invokingxe2x80x9d and xe2x80x9cenabling executingxe2x80x9d as used herein cover not only the consequences of user-interaction with the system, but also the supply of software and/or hardware components to the end-user to allow the system to show the behavior as specified.
The invention enables conditional state changes of software objects interconnected by routes, e.g., so as to keep their states consistent with each other. The mechanism proposed by the invention guarantees this consistency regardless of the direction of propagation of the state change along the route, herein after referred to as a two-way route.
Note that the invention is not restricted to COM, but can be used in any object-oriented software environment where changes in states can be propagated among objects without the need for a running client application.